Proposal by Steve Granda for Finish Physical Etoys port to Sugar

Proposed by (profile, biography) Don't forget to submit this proposal to official Google Melange site too!


How will I do that project

I intend on first getting a grasp of the codebase currently available by running it in different environments such as Window and Linux. Fortunately, I am able to do some testing using the latest Sugar release on one of the OLPC's I maintain as well as in a virtual machine.

The important feature I believe will be maintaining any cross platform compatibility and to make sure not break any modules throughout the project.

https://github.com/GIRA/Physical-Etoys

What methodologies will I use

For the environment I plan on working in a standard Debian/Windows virtual machine. Testing will also be done directly on an OLPC with the most up to date patches. 

I plan on keeping the codebase relatively similar to the existing style. Anything that is to be written should also be able to run with minimal libraries or without the use of too many beta/alpha packages to ensure reliability and future issues with incompatibility as upgrades may break the project in the near future. 

Suggested timeline and milestones

During the first couple days or week I plan on familiarizing myself with the current existing code base/conventions and set up an ideal environment (Debian/Sugar environment) similar to what the project developers may be using.In my office, I currently have access to a Wii Mote, Lego NXT, Arduino (Duemillanove), and a Microsoft Kinnect. I plan on using some of these to see what features may be missing and to get a general feel of where they are for the project. More importantly I want to see how these objects communicate to the operating system and Etoys.

The first milestone should be towards getting everything up and running in terms of familiarizing myself with the environment an the codebase.

From there I plan on delving into what methods are currently being used by the Physical Etoys project to communicate to the operating system (Sugar). My main goal is towards getting the Project to work on a virtual machine running Linux and an OLPC XO. If there is time, I would like this project to have compatibility with windows users as well. 

The second milestone is to get missing features ported and running on Linux and an XO.

From here I would like to address any issues regarding distribution of necessary libraries such as with the XO's by scripting or bundling the libraries with the main code. On a Linux machine I intend to write a simple python or perl script to import the necessary libraries.

The third milestone is to be able to release a version which can be easily installed on an XO by publishing it and having it able to be easily installed by users.

I would then like to work on any bugs and continue to make the project a bit better by adding any missing features or hardware support.

Where I see the risks

Many of the risks I see especially is making the project too hard to install or work with by the User. If the code base requires a large amount of libraries or additional packages the user must install to get it running on a simple XO, it might be an issue.

There are also various releases from the Linux community as well as the creators of Sugar Linux. I want to make sure that there is cross compatibility for example across various versions of libraries and potentially with any kernel upgrades. 

System stability is also another issue that may be potentially an issue. While the user is executing the application there is a potential for communication with the hardware to eat too much battery life or even potentially damage hardware with bad data. I want to make sure that the project works mostly well within the capabilities of an XO and not to demand too many resources with improper coding. 

 

How the results will look like

The project once implemented should be able to run as an application within Sugar on an XO or on Linux. Connecting devices should be simple and easily recognizable by the operating system without any disconnecting/reconnecting while the codebase polls for the hardware.

It should also be easily useable and installable by anyone with little to no IT intervention. 




Updated: 6.4.2012